Skip to content

feat(analyser): put the name resolver in front of the analyser 🔗 - #230

Merged
timfennis merged 3 commits into
feat/new-analyserfrom
feat/resolver-in-pipeline
Oct 13, 2026
Merged

timfennis merged 3 commits into
feat/new-analyserfrom
feat/resolver-in-pipeline

Conversation

@timfennis

@timfennis timfennis commented Oct 13, 2026 •

Copy link
Copy Markdown
Owner

Stacked on #226 so these changes can be reviewed apart from the resolver work itself. The resolver on feat/new-analyser produced its results but nothing used them. This PR runs it in front of the existing analyser, so it handles every program and test, as phase 1 of replacing the old analyser. Phase 2 will turn the old analyser into the type pass.

  • Keep going after errors: the resolver records one error per failing statement and carries on, including inside blocks, so a; b; reports both names like the current analyser does.
  • Resolve names before analysis: Analyser::analyse runs the resolver on each top-level statement first, with the registered natives as builtins. A statement with name errors isn't analysed further, so the same error isn't reported twice. The resolver's state is part of the analyser checkpoint, so a failed REPL line rolls it back. The compiler is unchanged.

Worth a look:

  • Behaviour change: a fn after a let of the same name in one scope is now an error, as decided for the resolver. 005_functions/034 became an error test, and the function page in the manual documents the rule.
  • Test fixtures: four analyser unit tests now declare the []/[]= natives their index assignments use, because the resolver rejects index access without them.
  • Unused fields: the AugmentedCandidates and StructSymbols fields only the type pass will read are marked expect(dead_code), so the marker becomes an error once they're used.

🤖 Generated with Claude Code

timfennis and others added 3 commits October 13, 2026 16:15
The resolver records an error per failing statement and carries on with
the next one, at the top level and inside blocks, so `a; b;` reports
both unknown names like the current analyser does. A failing statement
still stops at its first error.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The analyser runs the name resolver on each top-level statement first,
with the registered natives as builtins, and reports its errors as
analysis errors. A statement with unresolved names isn't analysed
further, which would only repeat its errors. The resolver's state is
part of the analyser checkpoint, so REPL lines that fail roll it back.

`fn` after a `let` of the same name in one scope is now an error, as
decided for the new resolver, so the functional test that relied on it
adding an overload now expects that error. The analyser's unit tests
for index assignment declare the `[]` and `[]=` natives they use.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 13, 2026 •

Copy link
Copy Markdown

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review Status Commit Review trigger
📝 Code Review ✅ Completed 2026-10-13T14:22:42.755019Z da6c433 PR opened
ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

@timfennis
timfennis force-pushed the feat/resolver-in-pipeline branch from da6c433 to 39d6c02 Compare October 13, 2026 14:26
@timfennis timfennis changed the title feat(analyser): put the name resolver in front of the pipeline 🔗 feat(analyser): put the name resolver in front of the analyser 🔗 Oct 13, 2026
@timfennis
timfennis merged commit 6174e55 into feat/new-analyser Oct 13, 2026
1 check passed
@timfennis
timfennis deleted the feat/resolver-in-pipeline branch October 13, 2026 14:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant